The presence system architecture helps to share the presence information of any user to others. The presence information basically is the information related to user like current location of user, available contact information for user, application specific information like Instant message related, User is online in IM client or offline, POC specific attributes etc. Currently user needs to subscribe to the presence information of the required user, and then other user authorizes the user for seeing his presence information. The Presence Server entity maintains the presence subscription and stores the presence information of users. As soon as presence information of user changes, Presence Server sends the notification to the Watchers. The Watchers are basically users who are authorized to watch presence attributes of a user. Currently once user subscribes to presence information he will continuously receives the notification of presence information change. The SIP SUBSCRIBE and SIP NOTIFY methods are used for the subscribing and notifying. There is huge notifications and publications traffic which is the primary concern for the network operators. As number of user increases load will be further increasing. As per current state of art, there are cases where unnecessary notification traffic flows through network entity and access network.
The current state of art supports the definition of filters for the presence information in a notification body. The notification body consists of various presence information of Presentity. There are number of presence attributes for a user, so Watcher may not be interested in all presence attributes. This is achieved by defining the filters in SUBSCRIBE body. User will define the filter rules in the subscription body which filter help in subscribing the required presence attributes. This filter rules are defined in the IETF draft Functional Description of Event Notification Filtering draft-ietf-simple-event-filter-funct-05⊚ This filtering rule also defines the rules for when to send the notification, by setting the particular condition for some presence attributes for e.g. status for Available presence attributes changes from Offline to Online then send the notification. These kind of filtering rules can be assigned in the body of subscribe request, so this filtering rules are use to set the content level.
The current state of art described above has the following limitations.
1. Currently notification is issued after each modification of presence attributes, notification traffic is very high.
2. Unnecessary notifications are not possible to block in current scenarios.
3. Currently user cannot control the notification based on there preferences.
4. Sometimes user uses multiple clients, user doesn't want to receive notifications on some client devices, this can not be achieved using current state.
Current filter mechanism defined by IETF basically is for content and notification rate controlling rules, but this innovation basically aims to block the notifications based on the presence attributes of the Watcher. These rules allow blocking unnecessary presence notifications when the user is busy or user is not willing to receive notification (based on device capability). This helps in controlling notification traffic and help user to set notification blocking filtering rules.